1. Field of the Invention
This invention is related to the security of web applications run on a computing device. Specifically, but not intended to limit the invention, embodiments of the invention are related to enabling the secure distribution of JavaScripts to computing devices and protecting JavaScript source code from unwanted distribution and/or modification.
2. Relevant Background
JavaScripts stored on remote network devices are used extensively in many websites and web applications. The source code of JavaScript files downloaded to a local, client device for use in such websites and web applications is often cached on the local device. This source code may be viewed as a separate file on the local device, or the user may view the JavaScript source code by viewing a website or web application HTML code, which may comprise embedded JavaScript code.
JavaScript source code provides portability across platforms, and allows the JavaScript program to be taken, modified, and/or used at will in other web pages and/or web applications. Therefore, the JavaScript developer's invention embodied in the code is not protected. Through the free distribution of unprotected JavaScripts, the ability for website and application owners to differentiate their goods and services from their competitors is diminished. The value of the unique services which are incorporated into JavaScripts becomes limited and short-lived. Furthermore, enabling JavaScript source code in a web browser or other web application may also enable the JavaScript to expose security holes in the browser and applications. An example of this is a JavaScript program which uses WebGL to implement 3D features, which exploits off-screen memory access or creates denial of service (DoS) problems with the device.
In order to try and overcome the ability to view native JavaScript code on a client device, developers sometimes implement byte-code generation to an intermediate format or obfuscation. However, both solutions fall short of providing sufficient protection of the code for the developer. Such existing solutions depend on developers using native (e.g., C/C++) sandbox implementations along with some plugin package managers (e.g., pNACL/NACL in Chrome browsers with Pepper Plugins—brings in yet another language C/C++ together with JavaScript). NACL and pNACL fail to address JavaScript source code copying, only considering C/C++ source code and the native code generated from them. Also the intention of pNACL/NACL has not been source code protection, but rather providing higher performance by using native C/C++ code for time critical parts of the web application.
In current solutions using obfuscation, one may still recover back JavaScript source that may have (i) new “non-understandable” names; (ii) renamed functions and variables; (iii) compressed JavaScript files using a unique compression algorithm; (iv) removed comments and white spaces; (v) added finishing semi-colon (i.e., “;”) where ever appropriate; and (vi) a new list of function and variable names. For example, function ADD(a, b){var c; c=a+b;} may be converted to var_0x9f27=[ ];function ADD(_0x64f2x2,_0x64f2x3) {var_0x64f2x4;_0x64f2x4=_0x64f2x2+_0x64f2x3;}. Such byte-code based intermediate forms (e.g., LLVM bitcode) can be converted back to JavaScript source code, as demonstrated by Mozilla in “Emscripten: An LLVM-to-JavaScript Compiler”. Since current byte-level intermediate-code formats can be converted back to JavaScript, machine-independent intermediate code formats are not optimal for protecting JavaScript source code.